Skip to main content

How to Create and Manage Runners

There are two types of runners: self-hosted and GitHub-hosted. GitHub has standardized runners for you, but you can also create larger runners with more resources.

Ephemeral​

GitHub runners are ephemeral meaning they are created on the fly and destroyed when the job is complete. This is the default behavior for GitHub-hosted runners.

Auto-scaling and Scale Limits​

If you hit scaling limits you can ask your AM or support to increase your concurrency limit.

ARC: Actions Runtime Configuration​

You can automatically scale your self-hosted runners in response to webhook events.

Runner Groups​

Runner groups simply allow you to manage which runners are available to which repositories. This is useful if you have a runner that is only available to a specific team.

GHR Networking​

By default, GitHub-hosted runners have access to the public internet. However, you may also want these runners to access resources on your private network, such as a package registry, a secret manager, or other on-premise services.

API Gateways​

You could run an API gateway on the edge of your private network that authenticates incoming requests with the OIDC token and then makes API requests on behalf of your workflow in your private network.

Wireguard​

Static IPs​

You have the option to create static IP addresses for your GitHub-hosted runners. This is useful if you need to whitelist the IP address of your runner in a firewall rule, for example.

VNET Injection (Azure Private Networking)​

You can use VNET injection to connect your GitHub-hosted runners to your Azure virtual network.

Runner Labels​

You label your runners to make it easier to target them in your workflows.

Example of using multiple runner labels
YML
runs-on: [self-hosted, linux, x64, gpu]